1. Field of the Invention
The present invention relates to a method utilized in a mobile communication environment, and more particularly, to a method of handling machine-type communication (MTC) in a mobile communication environment.
2. Description of the Prior Art
Machine-type communication (MTC) is one type of data communication including one or more entities not requiring human interactions. That is, the MTC refers to the concept of communication based on a network such as the existing GERAN, UMTS, long-term evolution (LTE), or the like used by a machine device instead of a mobile station (MS) used by a user. The machine device used in the MTC can be called an MTC device. There are various MTC devices such as a vending machine, a machine of measuring a water level at a dam, etc. That is, the MTC is widely applicable in various fields. The MTC device has features different from that of a typical MS. Therefore, a service optimized to the MTC may differ from a service optimized to human-to-human communication. In comparison with a current mobile network communication service, the MTC can be characterized as a different market scenario, data communication, less costs and efforts, a potentially great number of MSs for communication, wide service areas, low traffic per MS, etc.
Meanwhile, the number of MTC devices is expected to be much greater than the number of legacy devices, and a probability of performing operations of the plurality of MTC devices simultaneously is high due to a feature of a typical machine-to-machine (M2M) service. M2M communication (also referred to as “machine-type communications” or “MTC”) may be used in a variety of areas. In the area of security, M2M communication may be used in surveillance systems, in backup of telephone landlines, in the control of physical accesses (e.g. to buildings), and in car/driver security. In the area of tracking and tracing, M2M communication may be used for fleet management, order management, Pay As You Drive (PAYD) applications, asset tracking, navigation, traffic information applications, road tolling, traffic optimization, and steering. In the area of payment systems, M2M communication may be used in point of sales, vending machines, customer loyalty applications, and gaming machines. In healthcare, M2M communication may be used for remotely monitoring vital signs, supporting the elderly or handicapped, in web access telemedicine points, and in remote diagnostics. In the area of remote maintenance/control, M2M communication may be used in programmable logic controllers (PLCs), sensors, lighting, pumps, valves, elevator control, vending machine control, and vehicle diagnostics. In the area of metering, M2M communication may be used in applications related to power, gas, water, heating, grid control, and industrial metering. Additionally, M2M communication based on machine type communication (MTC) technology may be used in areas such as customer service.
M2M communications may take advantage of deployed wireless networks based on Third Generation Partnership Project (3GPP) technologies such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-Advanced), and/or other technologies such as WiMAX (Worldwide Interoperability for Microwave Access) or those developed by the Institute for Institute of Electrical and Electronics Engineers (IEEE) and 3GPP2. M2M communications may use networks based on these technologies to deliver business solutions in a cost-effective manner. In a circumstance involving ubiquitous deployment of wireless networks, the availability of the wireless networks may facilitate and/or encourage the deployment and use of M2M devices. Additionally, further enhancements to these technologies may provide additional opportunities for the deployment of M2M-based solutions.
To receive services, e.g. evolved packet system (EPS) services, the UE needs to register with the network. During a registration procedure, e.g. attach procedure, the UE may first send an “ATTACH REQUEST” message to a network entity (e.g. MME). The “ATTACH REQUEST” message includes an international mobile subscriber identity (IMSI), which is stored in a subscriber identity module (SIM) card inside the mobile device, e.g. UE. Because the IMSI uniquely addresses each subscriber, it is seen as critical information from a security point of view and its transmission clearly has to be avoided as much as possible. By spying on and monitoring the IMSI, eavesdropper may track a subscriber's location, movement, and activities. So the network allocates a temporary UE identity, for example a system architecture evolution (SAE) temporary mobile subscriber identity (S-TMSI), to the UE and renews it frequently in order to reduce the use of IMSI.
According to 3GPP TS 23.401, the network applies non-access stratum (NAS) level congestion control to avoid NAS signaling overload from massive UEs accessing the network in which the MME/serving GPRS support node (SGSN) provides a back-off timer to a requesting UE. When the back-off timer is running, the requesting UE is restricted from requesting subsequent EPS Mobility Management (EMM)/EPS Session Management (ESM) NAS signaling messages until the back-off timer expires.
In the prior art, the network lacks of a back-off status management mechanism for a back-off UE in which a back-off timer is running. For example, when the MTC server sends a trigger request message to the back-off UE, the network (e.g. MME/SGSN or HSS/HLR) would handle the trigger request message based on the EMM/EPS Connection Management (ECM) status of the back-off UE (i.e. a MTC device corresponding to the MTC server). The network may send trigger request message to the back-off UE or queue the trigger request message when the NAS level congestion control is applied. However, the MTC server does not get any response for the result of the trigger request message, such that the trigger request message is kept queued in the network. Network resources would be wasted and other trigger request messages for other non-back-off UEs may be delayed due to the queued trigger request message. Furthermore, if there is a validity timer in the trigger request message as indicated in 3GPP TR 23.888, the trigger request message would be invalid due to expiration of the validity timer, and the MTC server would occupy the network resource to resend the trigger request message.
A Device Trigger Delivery Gateway could be a standalone physical entity or a functional entity. At least one Device Trigger Delivery Gateway is owned by and deployed in a HPLMN that supports the MTC device trigger feature for subscribed devices. The DT-GW is deployed on the boundary between the HPLMN and the public Internet. Alternatively, the DT-GW is owned and operated by a 3rd party on behalf of the HPLMN and/or deployed in the public Internet. In which case, a secure tunnelling mechanism between the DT-GW and the HPLMN is utilized.
The MTC server sends a trigger indication request to the appropriate DT-GW encapsulated in an IP packet. The trigger indication request could contain pertinent information needed to route the trigger (e.g. device subscriber identity, trigger command/arguments, relevant device location information, security parameters, etc.). When a trigger indication is received from a submitting node (e.g. an authorized MTC server or IWK function on behalf of the MTC server), the DT-GW should first authorize the received request; making sure it originated from a trusted MTC server and is targeted for a device for which the MTC server is authorized to trigger. The next step is for the DT-GW to determine the reachability of the MTC device. Per the requirements specified in clause 5.8 of 3GPP documentation TS 22.368b.1.1, a trigger-able MTC device can be received in the detached state, in the attached state without a publically routable PDP context/PDN connection and in the attached state with a publically routable PDP context/PDN connection.
When the MTC server sends trigger request for the target MTC device to the network, e.g. HSS/HLR or DT-GW/MTC-IWF, the network may not be able to process the trigger request due to network congestion. However due to lacking of network congestion information, it is still not clear how the network, e.g. HSS/HLR or DT-GW, suppresses the received trigger request or incoming trigger requests when network is congested.